1. Field of the Invention
The present invention relates generally to methods for enhancing security of electronic transactions, and more particularly, to a method for authenticating electronic financial transactions conducted over two-way transmissions via cable alone or via cable in conjunction with a telephone connection.
2. Description of Related Art
The conventional use of cable is for the delivery of video entertainment to the home subscriber. In response to the need to enhance existing services of cable operators, cable equipment vendors have developed terminals and stand-alone modems which support the transmission of data over cable. The data transmission service is offered in addition to the delivery of video entertainment.
Currently, there are two types of data transmission: the one-way transmission and the two-way transmission. The one-way transmission allows text and graphics to be transmitted and displayed on the home television receiver, possibly simultaneously with video data. In addition to transmission of text, graphics, and video data, the two-way transmission allows bi-directional transmission of Internet Protocol (IP) data between the cable subscriber terminal and the cable distribution hub. For small systems, a third party can assume the function of the cable distribution hub.
While two-way communication is possible over cable, i.e., upstream transmissions to and downstream transmissions from the cable distribution hub, less than half of the existing systems are equipped to support upstream transmissions via cable. In the systems where only downstream transmissions via cable are possible, a telephone modem can be made part of the subscriber terminal to provide the upstream transmission capability.
Two-way communication allows financial transactions to be conducted between a cable subscriber and a merchant.
In order to better support electronic transactions over open networks such as the Internet, Visa and MasterCard have developed the Secure Electronic Transaction (SET) protocol to protect the privacy and security of their customers. This protocol takes over when agreement has been reached between the merchant and the cardholder as to the terms of the sale. For the simplest of transactions, the information flow is as follows.
The cardholder first sends a PInitReq message which contains various identifiers, housekeeping data including digests of all certificates in the cardholder computer. One of these certificates binds the cardholder's identity to his public key. Other certificates validate responses from the merchant. This PInitReq message is optional and contains no encrypted data.
The merchant then sends a PinitRes response which, in addition to the housekeeping data, contains reference to lists of revoked certificates. The cardholder's software uses the lists to reject cancelled merchant certificates in its possession. This PInitRes message which is the response to PInitReq message is also optional and contains no encrypted data.
The cardholder then sends a PReq response which contains encrypted cardholder data, and a digital signature which is not within the encrypted data envelope as well as cryptographic construct that links the ordering information with the payment information. Payment data is "tunneled" through to the acquiring bank without being revealed to the merchant. The digital signature format requires inclusion of the certificates that validate the signature.
The merchant then sends a PRes response which gives the status of transaction and housekeeping data, such as authorization and posting dates, etc., associated with the financial transaction. The PRes message is sent in the clear, i.e., with no encryption, but is authenticated with the merchant's digital signature.
Cardholder certificates are used when making an electronic purchase to insure that cardholder information has not been improperly appropriated and used to fraudulently obtain goods and services. SET uses digital signatures and cardholder certificates to ensure the authentication of the cardholder account.
The credit card does not have to be part of the transaction process if the card number or its cryptographic surrogate is stored in the terminal. Since the terminal in any of the cryptographic procedures in SET protocol would not necessarily have to read data from the credit card, the SET process really authenticates the terminal that is participating in the transaction, and only incidentally authenticates the card to which the transaction will be charged.
Thus, the SET protocols have a potential flaw: if the terminal is stolen, or if its software is copied, or if the terminal is somehow commandeered, fraudulent transactions will appear to be perfectly valid and, therefore, will be undetected.
When the authenticating certificate was granted, the terminal did pass the test of being in the possession of a legitimate cardholder. The problem with relying on the SET protocol alone is that no ongoing check is made of whether the legitimacy of the terminal has been compromised afterwards.
Accordingly, it is desirable to have a method and a system for correcting this deficiency.